import { Meta } from '@storybook/addon-docs'; import image01 from './assets/formulario/1.png'; import image02 from './assets/formulario/2.png'; import image03 from './assets/formulario/3.png'; import image04 from './assets/formulario/4.png'; import image05 from './assets/formulario/5.png'; # Formulario / Form Los formularios son un patrón de recogida de datos que permiten al usuario proporcionar la información requerida en una solución digital. Los formularios pueden ser simples o complejos, y se pueden presentar en una o varias páginas dedicadas, dentro de paneles laterales o en diálogos dependiendo del caso de uso y la situación. Son un patrón muy común en los interfaces de usuario, y su diseño evoluciona de manera continua a medida que se establecen nuevos componentes, se añaden nuevas funciones o se establecen nuevas maneras de uso. Algunos casos típicos de formularios serían los diseñados para el acceso al área privada de soluciones como la Sede de la Seguridad Social (sign-up o login), para recoger datos necesarios para la ejecución de un trámite, configurar opciones, rellenar una encuesta o una solicitud de información, sugerencia o queja… Los formularios se emplean para recoger información de una manera estructurada, exigen al usuario organizar su pensamiento, y como tales son bastante molestos para el usuario, así que se recomienda ser lo más concisos posible cuando se diseñan los mismos. Los formularios cortos son los más efectivos, conviene analizar con detalle si cada uno de los campos del formulario añaden datos con valor significativo. Para simplificar el uso de los mismos se recomienda agrupar los tipos de datos requeridos en distintas secciones, claramente diferenciadas y con títulos descriptivos, seguir un orden lógico en la toma de datos, facilitar la entrada de información rellenando previamente los campos con información que esperamos, usar facilitadores como textos de referencia o ayudas… Es importante el respeto a la privacidad de los datos del usuario, solicitando únicamente aquellos datos que son necesarios en cada momento y cumpliendo las normativas GDPR y cualquier otra de aplicación para la protección de datos personales. Con caracter ilústrativo hemos creado un **formulario de ejemplo**, ficticio pero posible, que modelaría la toma de datos básicos de un usuario para la realización de un trámite de cita previa con un servicio de la Seguridad Social.


### Elementos de un formulario Los formularios se componen de múltiples elementos. Estos elementos dan sentido a un patrón de captura de datos que se implementa como una combinación de múltiples componentes unitarios. - **Informaciones**: Orientan al usuario dentro del formulario y le explican los distintos elementos o grupos que se va encontrando. Pueden ser cabeceras o textos descriptivos en las distintas secciones del mismo, o etiquetas que informan al usuario del significado del campo de entrada correspondiente. - **Campos de entrada:** Permiten al usuario proporcionar información mediante diferentes medios, campos de texto que permiten la introducción de información en formato de texto libre, y campos de datos que permiten la selección de información de un conjunto ofrecido (botones de radio, casillas, selectores, desplegables…). - **Ayudas**: Proporcionan asistencia en cómo rellenar el campo correspondiente, mediante textos de referencia, textos de ayuda, campos pre-rellenados con valores por defecto, descriptores emergentes… Elementos que permiten al usuario proporcionar la información correcta de una manera sencilla. - **Acciones:** Permiten al usuario enviar los datos o salir del formulario cancelando el envío de datos. Se pueden ejecutar otras acciones dentro de un formulario como avanzar en pasos de la toma de información, descargar la información proporcionada… dependiendo de cada caso concreto. - **Validaciones:** Aseguran que se ha recogido toda la información requerida en cada caso, y que los datos proporcionados cumplen una serie de parámetros de aceptación. Los formularios se pueden organizar bien como una única unidad dentro de una página, o en distintos **bloques** o **grupos de elementos**. Típicamente las agrupaciones de elementos suelen tener un encabezado que describe el contenido. Asimismo se puede tener textos auxiliares, párrafos de texto, que detallan la información del grupo de elementos. Las **etiquetas** dotan de significado a los campos de entrada. Es por ello recomendable que los textos sean efectivos para ayudar al usuario a entender qué información ha de introducir. Todos los campos han de tener una etiqueta a no ser que el propio campo sea auto explicativo (como por ejemplo la casilla de autorización de uso de datos personales), o la etiqueta se aplique a un grupo de campos (como por ejemplo un conjunto de botones de radio). Las etiquetas han de ser concisas y claras, y deben diferenciar unos campos de entrada de otros. Las etiquetas deben ser claramente visibles y se debe entender fácilmente a qué campo hacen referencia. En **Grafito** se recomienda la utilización de etiquetas sobre los campos, de la manera que se ha detallado en los distintos componentes. Este tipo de etiquetas frente aquellas alineadas a la izquierda del campo permiten la vinculación rápida al campo y facilitan la rápida comprensión del usuario, así como la escalabilidad en las descripciones del campo. Los **campos de texto** que permiten la introducción de información en un formato libre son los elementos más habituales en los formularios. Los componentes usados para esta función es el campo de texto para datos de pocas palabras (nombres, teléfonos, emails…), el área de texto para información de varias líneas (por ejemplo sugerencias, solicitudes especiales…), y las variaciones y combinaciones de campos de texto para información específica (como por ejemplo contraseñas) o más compleja y con formato (como por ejemplo direcciones). El tamaño de los campos de texto deben ajustarse al contenido esperado, aunque se recomienda que se adapte lo máximo posible a las retículas de la página, tanto a las columnas como a la de miniunidades, y siempre garantizando que el usuario puede introducir la información en dispositivos de menor tamaño. Las ayudas, que veremos posteriormente, son recomendables para asistir al usuario. Así como el pre-rellenado de información. También se recomienda que el foco quede activo en el primer elemento del formulario y que su avance sea ordenado dentro del mismo. Los **campos de datos** son controles que sirven para recoger información de un rango limitado de valores planteados. **Grafito** define una gran cantidad de componentes que permiten esta captura de información, cada uno con unas características diferentes, como botones de radio, casillas, selectores, o desplegables (y sus variaciones como combo boxes, multiselectores…). Dependiendo del número de opciones que se ofrecen, de las características de las mismas, o de la cantidad de opciones que el usuario, puede seleccionar, de la interacción ofrecida…. se usarán unos controles u otros, tal y como se describe en el uso de cada uno de los componentes individuales. Otros campos de entrada de información híbridos permiten una entrada libre de datos con ciertas limitaciones como los campos numéricos, u otros campos que permiten solo introducir fechas, documentos de identificación, IBAN de cuentas bancarias… Los distintos campos, tanto de texto como de datos se deben posicionar de manera coherente. Esto es, las cajas deben estar alineadas y con tamaños consistentes entre si, los botones de radio y las casillas alineadas y con formatos similares… Las **ayudas** facilitan al usuario asistencia a la hora de proporcionar la información requerida. Hay varios mecanismos de ayudas, desde la utilización de valores por defecto pre-rellenados o pre-selecciones, textos de ayuda, descriptores emergentes… De manera general se recomienda incorporar todo tipo de ayudas que sea posible para facilitar la recogida de información. Si podemos anticipar qué opción es la más habitual, o la que se recomienda a un tipo de usuario, o conocemos parte de los datos que son necesarios aunque necesitamos confirmación de los mismos, se recomienda pre-rellenar campos y permitir al usuario cambiarlo si lo considera necesario. Algunos ejemplos de cómo prerellenar campos sería tener por defecto «España» como país de origen o nacionalidad, o la fecha actual como la fecha de inicio para búsquedas de citas… Se debe cuidar que el hecho de que el usuario no se de cuenta de que debe cambiar un campo prerellenado no suponga un error grave en el envío de datos. Los textos de ayuda de cada componente, facilitan al usuario cómo rellenar los distintos campos, al igual que los textos de ejemplo dentro de los componentes. Los textos de ayuda son más permanentes mientras que los ejemplos desaparecen cuando se empieza a escribir en el componente y por ello se emplean más para sugerencias con ejemplos sin valores reales, o indicar el formato de la respuesta requerida… Los descriptores sirven para ampliar la información o dar explicaciones adicionales, tanto extendiendo la información del texto de ayuda, o mediante iconos de información o «i». Estas ayudas deben ser breves, no mayor en tamaño que el propio componente, breves, concisas y directas, y muy orientadas a ayudar al usuario. No se recomienda utilizar estos mecanismos para proveer información importante o como forma de añadir información que no se puede guardar en otros sitios, para ello se recomienda usar las informaciones generales. En cuanto a las acciones, estas se articulan mediante **botones**, un único botón primario para la acción principal, botones secundarios para acciones secundarias (especialmente las de cancelación o anulación), y otros terciarios para acciones residuales o accesorias. Los botones se posicionan según su importancia, siendo este el medio de formalizar el énfasis de las acciones. Se recomienda que el botón principal sea posicionado a la derecha del grupo de botones, alineado a la derecha de la página, y decreciendo en jerarquía e importancia a medida que se posicionan hacia la izquierda de este. Se recomienda que las acciones, los botones, se sitúen en la parte inferior de la página. Esto garantiza que el usuario ha recorrido toda la página, ha podido revisar e introducir los datos requeridos, antes de ejecutar la acción deseada. Tampoco se recomienda el uso de botones para «volver» en la parte superior. Sí se recomienda acciones en el pie para «cancelar» una operación. Para volver a áreas o páginas anteriores ya hay herramientas como el rastro de migas, o indicadores de progreso de un proceso, o elementos como el menú en la cabecera o en el panel izquierdo, de la solución, incluso en última instancia, un botón de página anterior en el propio navegador. En cuanto a los literales que describen las acciones, aunque se recomienda que sean breves, no es recomendable utilizar términos genéricos como «enviar» puesto que dan una sensación de que el formulario es genérico, y no sirve para una actividad concreta. Por último en cuanto a las **validaciones** y **errores** de los formularios, estos deben estar orientados a la calidad de la información recogida y por tanto los mensajes deben ayudar al usuario a entender el problema que se presenta y cómo resolverlo. Para errores generales del formulario se emplean **notificaciones en línea**. No se debe usar este tipo de notificaciones para errores concretos en una parte del formulario o de un único componente. Estas notificaciones pueden mostrarse al tratar de enviar el formulario, al realizarse una validación general, o posteriormente al envío tras recibir una respuesta de error. Se recomienda realizar validaciones lo antes posible, mejor al introducir la información en el componente correspondiente que terminar con todos, mejor antes de enviar que una vez enviado y al llegar la respuesta. Los componentes tienen un **estado «error»** que permite indicar claramente qué componente concreto no es correcto, y además se puede dar información clara de la causa del error, empleando el texto de ayuda para indicar de la manera más informativa el problema. Una vez que el usuario ha corregido el error, se debe recuperar el estado «active». ### Diseño de formularios Cuando se diseña un formulario lo primero es pensar en para qué se necesita ese formulario y con ello se define un **encabezado del formulario** que lo describe. Este encabezado será el título de la página en formularios de página completa o el encabezado del contenedor donde se ubique el formulario en caso de que este sea parte de una página con más contenidos. La tipografía con que se escribe este encabezado será consistente con esta situación. De la misma manera que los contenidos, el formulario se puede dividir en distintos **bloques** de controles, agrupando la toma de datos de información que está relacionada. Se recomienda poner un **encabezado para cada bloque** que describa el propósito de cada bloque en concreto. Este encabezado debe tener una tipografía superior al título, pero obviamente menor que la del encabezado del formulario general. Cuando las explicaciones del contenido de los formularios o bloques son largas, más que tener encabezados largos, se recomienda mantenerlos breves y usar **textos de explicación** del contenido del bloque que permiten ampliar la información y que el usuario entienda la necesidad de los datos, su uso… En cuanto al **uso del color**, para formularios de página completa, colocaremos los bloques de formulario sobre el mismo fondo de todas las páginas de la solución, que en el lenguaje de referencia es blanco. Existe la posibilidad, para formularios que forman parte de una página con otros contenidos de, además de mantener el color de página, la alternativa de crear una sección específica y destacarlo con un fondo de color, que debe ser un color suave y que coincida con el fondo secundario usado en el resto de la solución, paneles, bloques, tarjetas…, que en el lenguaje de referencia es un gris claro. En cuanto a los componentes, como ya se ve en su descripción tienen una versión normal con color y una versión clara (light) sin fondo. Respecto a las **tipografías**, todos los componentes deben mantener las tipografías de referencia definidas, esto es una base de Lato 16px con elementos de soporte menores. Los distintos bloques, secciones, páginas, mantendrán una jerarquía tipográfico consistente a lo largo de toda la solución, de manera consistente con las páginas de contenidos. Es necesario que el usuario comprenda qué campos de un formulario son **obligatorios** y cuáles son **opcionales**. Se recomienda marcar específicamente los campos minoritarios con la etiqueta correspondiente («obligatorio» y «opcional»); esto es si la mayoría de los campos son obligatorios, se deben indicar expresamente los opcionales, y viceversa. Esto ayuda a reducir el ruido visula y simplificar el formulario. En caso de que todos los campos sean obligatorios u opcionales, conviene indicarlo al proincipio del formulario con un texto de ayuda «Todos los campos son obligatorios». Esta misma forma se puede usar para simplificar las indicaciones con un texto como «Todos los campos salvo los marcados con (*) son obligatorios». Los formularios se distribuyen en **columnas**. Las distribuciones más habituales es en una única columna o en dos columnas, aunque puede haber distribuciones con tres o hasta cuatro columnas en anchos de pantalla mayores, aunque son desaconsejados dada la complejidad que presentan para el usuario. La anchura de la columna depende del contenido y de la organización de la página. Cuando se estrecha el tamaño de la pantalla, para dispositivos móviles se reduce siempre a una única columna. A la hora de definir la **distribución** de los componentes de un formulario en las columnas y grupos se recomienda utilizar el sentido común, es decir, los componentes que tengan una relación (de negocio, funcional…) se han de agrupar y presentar juntos. Esto es especialmente importante a la hora de capturar información que requiere varios campos como por ejemplo un nombre con sus dos apellidos, una dirección completa con su calle, nupero, piso, letra, código postal y ciudada, o un pago con tarjeta con el número de tarjeta, su tutular, la fecha de expiración el código CCV. Los formularios se construyen con distintos componentes, distribuidos con un orden flexible, aunque se deben respetar las **reglas de espaciado**. Los usuarios se confunden si dos componentes no relacionados están demasiado cerca puesto que los vinculan mentalmente. De la misma manera, los componentes muy alejados, hacen que el formulario pierda su identidad. Los espacios entre componentes siguen los principios de la rejilla 2x que se aplica en los componente y los patrones. Los espaciados verticales coinciden con los espaciados de los contenidos definidos. En cuanto a los espaciados horizontales se ven afectados por la distribución entre columnas. En cuanto al **contexto** en que se presentan, los formularios pueden presentarse en distintas situaciones, unas que permiten mayor complejidad que otras, desde páginas dedicadas, dentro de una sección, en un panel lateral, hasta los más simples dentro de otros patrones o componentes como diálogos, tablas o tarjetas. En cuanto al **tamaño** de los componentes, como regla general se usaran los componentes por defecto de 40px, aunque en contextos más reducidos se puede utilizar la versión reducida de 32px. En cuanto la **posición**, en los contextos más amplios, se ajustará el formulario a la rejilla que garantiza su adaptación a distintos tamaños de pantalla. En otros contextos más reducidos se recomienda usar tamaños fijos adaptados al contenedor correspondiente y siempre respetando las reglas de espaciado. En cualquier caso se recomienda aplicar reglas de espaciado entre componentes consistentes y acordes a valores como 32px de distancia para componentes en formato normal, que puede reducirse en contextos menores a 24px o incluso 16px. Asimismo se recomienda un espaciado mayor al de separación entre componentes para separar secciones. En cualquier caso, estas distancias deben mantenerse a lo largo de los formularios en toda la solución. Los distintos grupos de componentes se deben diferenciar entre ellos, para ello se establecen **separaciones** ademas de etiquetas o títulos para los grupos. Estas separaciones dependen del contenedor y de los espaciados definidos, pueden ser espacios mayores o elementos como líneas divisoras. En cuanto a los **formularios largos**, es decir cuando se requiere una captura abundante de información, estos presentan una dificultad añadida puesto que pueden cansar o confundir al usuario. Hay distintas estrategias para facilitar el uso de esos formularios largos, y que se deben adaptar a la situación concreta, la solución digital, el caqnal, el perfil de los usuarios, el uso que estos hacen del formulario… La estrategia más habitual es la de descomponer el formulario en varios, estableciendo un proceso de captación de información por pasos que permite al usuario centrarse en un formulario menor. Cada uno de los formularios menores deben tener una identidad propia y requerir información relacinada. En estos casos, donde el formulario se distribuye en varias páginas, es recomendable utilizar elementos como el indicador de progreso que oriente al usuario, que le indique en que punto de la captura de la información está y lo que le queda, y le permita navegar a páginas previas. Otras estrategias que permiten incluir todos los componentes en una única página pero sin abrumar inicialmente al usuario es utilizar formularios dentro de acordeones, o la visualización progresiva de componentes ocultos ante elecciones previas del usuario. Por último, en cuanto a la **accesibilidad** de los formularios, , primero hay que consultar la accesibilidad específica para cada componente utilizado. Cada entrada de texto debe tener visible una etiqueta descriptiva, junto con instrucciones codificadas para el formato de entrada. En general, al diseñar formularios, se debe tener en cuenta que los requisitos para el formulario deben anunciarse y declararse antes de que el usuario rellene el formulario y que el desafío visual más importante al que se enfrentan los usuarios es la forma en la que se estructura el formulario para simplificar la recogida de información del usuario. ### Anatomía de formularios Como ejemplo de la anatomía de formularios vemos dos versiones diferentes de este mismo formulario, uno a pantalla completa con tres columnas de formulario y otro con formulario más reducido por la existencia de un panel de navegación lateral con dos columnas. Es importante destacar la **consistencia** de la anatomía de las páginas de formularios y las de contenidos, al formar parte de la misma solución. Esto es debe respetarse elementos comunes como cabeceras y títulos, así como la jerarquías de tipografías y espaciados planteadas. En el ejemplo de tres columnas, vemos un formulario a pantalla completa. Esta versión, menos recomendable que otras más comprimidas, se puede utilizar siempre que se diseñe con una estructuración clara y ordenada. Al igual que el panel de contenido, las distancias entre secciones (título, entradilla, formulario, botonera y pie) son un macroespaciado de 48px, y las distancias entre bloques del formulario son un macroespaciado de 32px. Las distancias entre componentes son de 16px.
El formulario con panel lateral muestra un formulario regular de dos columnas. En este caso, las reglas de creación del formulario son las mismas, garantizando la consistencia a lo largo de la solución.
Por último, indicar que para la distribución del formulario se han utilizado las rejillas indicadas que facilitan la adaptación de la solución a dispositivos. Se ha optado por distribuir en 4 columnas al ser este número divisible por 3, teniendo así cada columna de formulario 4 columnas de rejila. En el caso del formulario con panel lateral, se reservan 3 columnas para éste dejando para el formulario el resto de columnas hasta 12 para su distribución según los requisitos del mismo.